Post not yet marked as solved
I have also run into the same issue. I've filed a bug under FB7456608. This seems to happen even with a simple test application that hooks into the ES framework, where there is a sleep(1) during the exec auth hook. I've been able to reproduce this more conistently when doing file and process execution heavy tasks. An example would be like compiling clang/llvm with a `make -j8`. This also seems to happen more consistently upon reboot and immediately firing up the ES client and then attemping to compile clang/llvm. Additionally I have also made sure to respond to the auth event BEFORE the deadline.
It seems like to me that if I am able to load a system extension from the context of a launchdaemon I should also be able to unload a system extension from the context of a launchdaemon. However from your explanation it seems like the inablilty to unload a system extension from a launchdaemon is by design. Would that be an accurate statement? Thanks!
I am building a NetworkExtension. The launchd daemon is the one that is currently attempting to load and unload the system extension. Perhaps the .plist will make things a bit more clear<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>MyApp</string>
<key>ProgramArguments</key>
<array>
<string>/Applications/MyApp.app/Contents/MacOS/MyApp</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>UserName</key>
<string>root</string>
<key>KeepAlive</key>
<true/>
<key>ThrottleInterval</key>
<integer>5</integer>
<key>StandardErrorPath</key>
<string>/dev/null</string>
<key>StandardOutPath</key>
<string>/dev/null</string>
</dict>
</plist>Once the launchd daemon starts, it will attempt to load the NetworkExtension that also located inside MyApp. The load succeeds and all the security prompts show up regarding loading a System Extension and allowing filtering of network traffic, however once we attempt to unload the System Extension, the call to deactivationRequestForExtension fails and we are unable to unload the System Extension unless we drag and drop MyApp to the trash bin. Is this correct behavior? There is also sample code attached with the bug report. Thanks!
I've submitted a bug report FB7458892
